home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 18275 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.6 KB
  1. Path: news.Stanford.EDU!not-for-mail
  2. From: bims@isl.Stanford.EDU (Harry V. Bims)
  3. Newsgroups: comp.object,comp.lang.c++,comp.realtime,comp.dcom.telecom.tech,comp.arch.embedded
  4. Subject: Re: Can OO be successful in real-time embedded systems?
  5. Date: 19 Apr 1996 11:40:13 -0700
  6. Organization: Stanford University
  7. Message-ID: <4l8mmd$s5o@isl.Stanford.EDU>
  8. References: <316BF0C5.1FE1@condat.de> <dibaldDpnpBH.5Et@netcom.com>
  9. NNTP-Posting-Host: isl.stanford.edu
  10.  
  11. In article <dibaldDpnpBH.5Et@netcom.com>,
  12. Dave Baldwin <dibald@netcom.com> wrote:
  13. >Henning Rietz (rietz@condat.de) wrote:
  14. >
  15. >: I can say "everybody" is using OO in some areas (mainly network
  16. >: management, switch provisioning, customer care), BUT there are (almost)
  17. >: no examples in the area of (small) embedded systems, main reasons for
  18. >: that being:
  19. >
  20. >:         - "OO systems are too slow"
  21. >:         - "OO systems eat up too much memory"
  22.  
  23. Quite the contrary.  Here are Wireless Access, I have designed and built
  24. a real-time, objected-oriented system running on a PC.  The system
  25. creates a local area two-way paging environment.  It schedules and
  26. manages multiple channels and users simultaneously.  A coomparable system
  27. was implemented without OO technology, and it requires a 250MHz Alpha to
  28. do the same job.  In addition, code changes can occur much more quickly
  29. when you have an OO framework to start with.  The problem is that
  30. very few people know how to create good OO designs.  It takes quite
  31. a long time to climb the learning curve.
  32.  
  33. As far as memory is concerned, there is some overhead associated with
  34. C++ compilation versus C, however, once your program reaches in excess
  35. of 15K lines, that no longer becomes an issue.  In fact, because of code
  36. and data reuse, my code is more efficient from a memory requirements
  37. perspective than the non-OO counterpart.
  38.  
  39. >
  40. >Object-dis-oriented programming is (like some others) intended to hide 
  41. >the hardware from the programmer.  How useful can this possibly be when 
  42. >small embedded systems are expressly for dealing with the hardware?  Some 
  43. >of the techniques can be useful, but the overhead and 'hiding' is exactly 
  44. >what you don't need in hardware control.
  45.  
  46. Hardware designs are subject to change.  When that happens, it is much
  47. more difficult to adapt your code when you DON'T use OO.  Again, overhead can
  48. be minimized through careful design.
  49.  
  50. >There is no universal programming method.  Even the examples you cite are
  51.  
  52. You are right.  However, if you are building a program that is longer than
  53. about 10K lines, OO is generally the best methodology.
  54.  
  55. Harry Bims
  56. Senior MTS
  57. Wireless Access, Inc.
  58. 408-653-2288
  59. disciple@waccess.com
  60.  
  61.